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Preface 


This  report  describes  the  work  performed  under  Phase  ill  of  Contract  DACA72-86- 
C-0017  for  the  U.S.  Army  Engineer  Topographic  Laboratories,  Fort  Belvoir,  Virginia,  by 
PAR  Government  Systems  Corporation,  Reston,  Virginia.  The  period  of  performance 
covered  by  this  report  is  December  1988  through  November  1989.  This  is  the  concluding 
phase  of  a  three  year  contract.  The  contracting  officer's  representative  was  Mr.  John 
Benton,  of  the  Research  Institute,  CEETL-RI-I. 
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1. 


Introduction 


This  report  describes  work  performed  during  the  period  from  February  1989 
through  November  1989  under  Phase  III  of  contract  DACA72-86-C-0017,  Expert  System 
for  Minefield  Site  Prediction. 

1 . 1  Scope  of  the  Report 

This  report  reviews  the  major  system  components  of  the  Mine  Site  Prediction 
Expert  System  (MSPES)  and  discusses  modifications  made  to  the  system  under  Phase  III 
of  this  contract.  Phase  III  development  was  a  natural  extension  of  the  system  developed 
under  Phase  II.  A  high-level  description  of  the  software  architecture  was  presented  in  an 
earlier  document  from  Phase  I  [Barth  et  al,  1987],  with  more  detailed  descriptions 
presented  in  the  Phase  I  and  Phase  II  Final  Reports  [ETL-0492,  February  1988;  ETL- 
0534,  May  1989], 

The  organization  of  this  report  is  as  follows.  Section  2  provides  an  overview  of  the 
system.  A  description  of  the  various  components  is  presented  in  Section  3.  Section  4 
contains  some  recommendations  based  on  evaluation  of  the  Phase  HI  developments. 

1.2  Scope  of  the  Phase 

The  scope  of  Phase  III  was  the  implementation  of  a  second  knowledge  base  which 
incorporated  enemy  location  and  line  of  sight  factors  for  minefield  site  prediction.  Phase 
HI  MSPES  development  continued  on  the  Sun  3/160  at  the  request  of  the  ETL.  The 
transporting  of  the  system  to  the  target  computer,  a  VAXStation  II  GPX,  was  scheduled 
for  Phase  HI.  Based  on  the  review  and  evaluation  at  the  end  of  Phase  II,  however,  it  was 
determined  that  the  system  should  not  be  transported  to  the  VMS  environment.  Phase  III 
effort  was  concentrated  in  two  areas:  first,  the  implementation  of  a  second  processing 
methodology  and,  secondly,  the  implementation  of  a  second  knowledge  base. 

1.3  Summary  of  Work  Performed 

The  major  results  of  the  work  performed  under  Phase  IE  were  the  following: 

•  User  interface  implementation  .  To  make  the  MSPES  more  transportable  to  other 
machines,  the  user  interface  under  Phase  II  was  implemented  using  the  X  Window  System 
(XI 1),  a  graphics  package  originally  developed  at  the  Massachusetts  Institute  of 
Technology  (MIT).  Phase  HI  extended  the  X  Window  implementation  to  enhance  analyst 


interaction  with  the  MSPES.  Several  modifications  were  made  in  the  window  system 
interface  software  to  adapt  to  the  changes  that  occurred  between  release  2  and  release  3  of 
the  XI 1  Window  System. 


•  Rule  base  development.  The  knowledge  base  expansion  in  Phase  III  was 
significant.  Based  on  analyst  input,  reasoning  involving  enemy  location  and  visibility  was 
incorporated  in  the  rule  base. 

•  Processing  efficiency.  An  additional  processing  method  was  developed  which 
takes  advantage  of  the  GIS  functions  and  uses  Boolean  operations  to  form  an  inference 
template.  This  process,  combined  with  some  modifications  to  the  manuscript  update 
software,  decreases  the  inference  processing  and  thus  dramatically  reduces  processing  time 
for  production  of  a  minefield  manuscript. 
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2. 


Overview  of  the  System 


The  goal  of  the  MSPES  is  to  automate  some  of  the  functions  performed  by  the 
terrain  analyst  and  the  combat  engineer  in  the  determination  of  potential  minefield  sites. 
The  factors  used  in  minefield  site  prediction  include  terrain  information,  such  as  mobility 
information;  mine  and  countermine  warfare  doctrine,  as  found  in  military  training  manuals; 
and  battlefield  situation  or  enemy  intention  knowledge,  as  supplied  by  battlefield 
intelligence.  Developing  the  MSPES  involves  elements  of  military  terrain  analysis,  which 
in  turn  encompasses  both  geographic  analysis  and  military  doctrine.  The  system  therefore 
comprises  a  geographic  information  system  (QUILT)  for  handling  the  terrain  information; 
an  inferencing  mechanism  (ERS)  for  coordinating  rules  about  how  the  doctrine  exploits  the 
terrain  information  in  making  minefield  site  predictions;  and  a  direct  manipulation  user 
interface  based  on  a  windowing  graphics  package  (XI 1)  to  provide  the  analyst  working  in 
this  domain  with  a  consistent,  intuitive  environment  for  interacting  with  the  GIS  and  the 
inferencing  mechanism. 

The  individual  system  components  (QUILT,  ERS,  and  user  interface)  were 
previously  discussed  in  the  Phase  I  and  Phase  II  Final  Reports.  Phase  III  modifications 
and  enhancements  to  the  system  components  are  discussed  in  detail  in  Section  3.  In  this 
section,  a  scenario  is  presented  that  describes  how  manuscripts  are  created.  The  scenario 
illustrates  the  interactions  among  the  system  components,  and  details  the  two  processing 
methods  developed. 

2.1  An  Illustrative  Scenario 

The  terrain  overlays  associated  with  an  Area  of  Interest  (AOI)  and  a  rule  base  are 
the  necessary  inputs  to  start  the  process  in  which  the  ERS  inference  engine  may  run.  The 
textual  rule  base  that  the  analyst  has  selected  is  read  from  a  disk  file  and  is  compiled.  The 
compiled  rules  become  the  inference  network  for  ERS.  The  inference  network  drives  the 
process  of  gathering  evidence  for  the  various  hypotheses  about  a  location  being  a  mine  site. 

Locations  to  be  evaluated  are  specified  to  ERS  by  the  Create  Manuscript 
application  or  the  Explain  Manuscript  mode  of  the  View  Map  application.  The 
Create  Manuscript  application  gets  its  AOI  locations  from  a  geographic  primitive, 
whereas  the  Explain  Manuscript  mode  of  the  View  Map  application  gets  its  AOI 
locations  from  the  analyst  interactively. 
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The  evidence  in  support  of  ERS's  inferential  hypothesis  comes  from  GIS 
primitives.  The  primitive  processes  that  ERS  uses  are  started  as  needed  following  the 
compilation  of  the  inference  network.  The  relationship  of  the  terrain  characteristics  relative 
to  a  location  provide  evidence  to  ERS.  ERS  uses  this  evidence  as  the  basis  for  an 
evaluation  of  the  likelihood  of  the  location  being  a  mine  site.  The  evidence  in  support  of 
the  possible  hypotheses  is  evaluated  and  the  hypothesis  with  the  highest  'score'  becomes 
the  evaluation  for  the  specified  location. 

The  Create  Manuscript  application  sends  this  evaluation  back  to  the  geographic 
primitive  that  initially  reported  the  location  coordinates.  This  primitive  updates  the  value 
associated  with  the  location  to  reflect  the  mine  site  likelihood  evaluation.  Since  the  data 
base  file  used  for  this  purpose  is  never  accessed  by  ERS,  this  evaluation  does  not  bias  later 
evaluations.  The  Explain  Manuscript  mode  of  the  View  Map  application  reports  the 
evaluation  and  related  rule  base  information  to  the  analyst  through  a  window-based 
interface  to  ERS.  The  analyst  may  review  the  evaluation  in  terms  of  the  evidence  compiled 
supporting  the  hypothesis  and  the  inferencing  process  and  may  choose  to  edit  the 
manuscript,  edit  the  rule  base,  or  to  accept  the  evaluation. 

2.2  Method  I 

To  produce  a  minefield  manuscript  using  Method  I,  the  analyst  first  specifies  enemy 
location(s)  if  known.  Upon  completion  of  the  enemy  location  edit  process,  overlays  that 
are  dependent  on  enemy  location  are  created.  These  include  the  calculation  of  forward 
facing  slopes  (areas  that  are  visible  from  enemy  locations)  and  ranges  of  minimum  distance 
to  enemy  location.  If  enemy  location  is  not  known,  these  processing  steps  are  simply 
omitted  and  the  minefield  likelihood  evaluation  will  be  based  solely  on  terrain  factors  and 
other  "permanent"  data  if  available.  The  analyst  then  selects  an  overlay  to  serve  as  the 
template  for  a  minefield  manuscript  production.  This  overlay  will  be  the  guide  for  the 
inferencing  process,  indicating  which  areas  should  be  evaluated.  Any  areal  overlay  may  be 
used,  for  example,  the  off-road  mobility  overlay  is  often  used  as  the  template  for  a 
manuscript. 

For  each  area  in  the  selected  manuscript  template: 

•  The  GIS  passes  an  area  identifier  to  the  Create  Manuscript  application  to  be 
evaluated  by  the  inferencing  mechanism. 

•  The  application  passes  the  area  identifier  to  ERS,  the  inferencing  mechanism. 
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•  ERS,  driven  by  the  inference  net,  calls  GIS  primitives  required  to  make  a  final 
evaluation. 

•  ERS  passes  its  evaluations,  as  they  are  made,  back  to  the  application. 

•  The  application  passes  the  final  evaluation  back  to  the  GIS. 

•  The  GIS  updates  the  current  quad  with  the  final  evaluation  value. 

•  The  next  area  identifier  is  found. 

2.3  Method  II 

To  produce  a  minefield  manuscript  using  Method  n,  the  analyst  also  specifies 
enemy  location(s)  if  known.  This  part  of  the  process  is  the  same  as  under  Method  1. 

With  Method  II,  the  manuscript  template  is  constructed  by  combining  (intersection 
overlay  operation)  all  of  the  overlays  to  create  quads  with  a  unique  value  wherever  a 
different  combination  of  attribute  values  exist.  This  is  done  by  first  combining  the  overlays 
that  contain  multiple  attribute  values,  such  as  the  mobility  and  distance  range  to  enemy 
location  overlays.  Subsequently  the  overlays  that  merely  denote  the  presence  or  absence  of 
an  attribute  value,  e.g.,  areas  that  are  visible  or  not  from  enemy  locations,  are  combined 
with  the  results  of  the  previous  step.  The  result  is  a  manuscript  template  which  defines  an 
identifying  value  for  each  unique  combination  of  attribute  values  for  every  location  of  the 
area  of  interest.  Finally,  each  unique  combination  of  attributes  is  marked  as  'unevaluated'. 

For  each  unevaluated  combination  of  attributes  in  the  manuscript  template: 

•  The  GIS  passes  an  area  identifier  to  the  Create  Manuscript  application  to  be 
evaluated  by  the  inferencing  mechanism. 

•  The  application  passes  the  area  identifier  to  ERS,  the  inferencing  mechanism. 

•  ERS,  driven  by  the  inference  net,  calls  GIS  primitives  required  to  make  a  final 
evaluation. 

•  ERS  passes  its  evaluations,  as  they  are  made,  back  to  the  application. 

•  The  application  passes  the  final  evaluation  back  to  the  GIS. 

•  The  GIS  updates  this  area  and  every  other  area  whose  value  indicates  it  has  the 
same  combination  of  attributes  with  the  final  evaluation  value. 

•  The  next  unevaluated  combination  of  attributes  is  found. 
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This  processing  method  was  shown  to  be  at  least  five  times  more  efficient  than 
Method  I.  The  processing  time  to  complete  Method  I  is  dependent  on  the  number  of  areas 
with  a  homogeneous  value  in  one  of  the  areal  overlays;  using  the  nodect  QUILT  function, 
this  number  was  calculated  to  be  over  29,000  for  the  Lauterbach  mobility  overlay. 
Processing  time  to  complete  Method  II  is  dependent  on  the  number  of  unique  combinations 
of  attribute  values  for  all  the  overlays  in  an  area  of  interest;  for  the  10  or  so  overlays 
currently  available  for  use  by  the  MSPES  this  number  typically  was  shown  to  be  less  than 
200.  The  typical  processing  time  to  produce  a  minefield  manuscript  for  a  1 :50000,  25  km 
X  25  km  area,  is  about  ten  minutes  run  time  on  a  Sun  3/160  using  Method  EL  Using 
Method  I,  processing  time  can  exceed  one  hour.  Figure  2- 1  demonstrates  the  difference 
between  Method  I  and  Method  DL 

METHOD  1  METHOD  2 


Figure  2-1 .  Processing  Methods  I  and  II. 


3 .  System  Software  Description 


The  Phase  II  MSPES  software  components  are  organized  as  shown  in  Figure  3-1. 
MSPES  Applications,  the  Inference  System,  and  the  Geographic  Information  System 
access  rule  bases,  terrain  data,  and  map  descriptions  which  are  defined  in  disk  files. 
MSPES  Applications  and  the  Inference  System  have  user  interface  components  which  use 
Window  System  Interface  routines  to  present  textual  and  graphic  displays  to  the  user. 
MSPES  Applications,  the  Inference  System,  and  the  Geographic  Information  System 
communicate  data  amongst  themselves  as  each  requests  it.  The  MSPES  Applications  and 
the  Inference  System  communicate  with  the  GIS  via  GIS  primitive  processes,  each  of 
which  answers  simple  queries  of  the  data  base  maintained  for  an  Area  of  Interest.  This 
overall  organization  is  fundamentally  the  same  as  that  used  for  the  first  two  phases  of 
MSPES  development.  The  succeeding  sections  will  discuss  the  major  modifications  to  the 
MSPES  during  Phase  ID,  using  reference  to  earlier  Phases  for  background  information. 


Figure  3-1.  MSPES  Phase  ID  Components. 

3.1  Input  Conversion 

The  Phase  II  MSPES  uses  two  basic  types  of  information  to  support  its  rule  base 
evaluation  of  terrain  characteristics:  vehicle  mobility  data  derived  from  the  Condensed 
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Army  Mobility  Model  System  (CAMMS)  and  transportation  network  information  derived 
from  ADDWAMS  transportation  features.  In  Phase  HI,  both  off-road  mobility  and  on-road 
mobility  were  provided  in  CAMMS  format  in  addition  to  elevation  data.  The  CAMMS  data 
used  for  Phase  III  development  and  testing,  provided  by  the  Waterways  Experiment  Station 
(WES),  was  in  a  different  format  than  that  used  for  Phase  II  CAMMS  data.  The  different 
formats  and  the  addition  of  elevation  data  in  Phase  in  necessitated  modifications  to  a 
number  of  existing  procedures  and  the  development  of  some  new  software  to  integrate  this 
format  data  into  the  MSPES  GIS  component.  Procedures  and  programs  to  convert  the 
older.  Phase  II  CAMMS  and  ADDWAMS  data  formats,  as  well  as  the  Phase  I SLF  data 
formats,  are  still  separately  available.  Not  all  of  the  procedures  necessary  to  prepare  data 
for  evaluation  with  the  Phase  III  rule  base  are  able  to  use  the  older  data  formats,  however. 
For  example,  the  programs  and  procedures  that  convert  the  CAMMS  road  data  used  in 
Phase  III  to  areal  quadtree  form  were  not  set  up  to  deal  with  the  ADDWAMS  format  road 
data  used  in  Phase  U. 

3.1.1  CAMMS  processing:  Off-Road  Mobility 

CAMMS  areal  attribute  data,  including  off-ioad  mobility  information,  is  imported  to 
the  system  as  a  raster  of  polygon  identifiers  keyed  to  attribute  look  up  tables  for  areal 
attributes  unique  to  each  polygon.  The  mobility  information  is  provided  as  an  attribute  look 
up  table  of  speed  values  for  a  particular  vehicle  type  across  the  terrain  of  a  map  sheet  given 
specified  weather  conditions.  The  MSPES  camms_cvl  process  converts  import  format 
polygon  identifiers  into  a  raster  format  used  by  the  GIS.  The  MSPES  cnvrt_attr  process 
converts  the  import  format  attribute  look  up  table  to  a  format  more  amenable  to  handling  by 
other  MSPES  processes.  The  speed2ccm  process  combines  the  polygon  identifier  raster 
and  the  CAMMS  mobility  speed  value  attribute  into  mobility  categories  (go,  restricted, 
slow,  etc.)  as  the  raster  is  converted  into  the  input  format  used  by  the  QUILT  package. 
The  default  mobility  category  breaks  are  easily  over-ridden  at  run  time  to  assign  different 
speed  values  to  the  mobility  categories.  The  mobility  categorized  CAMMS  data  is 
converted  to  an  areal  quadtree  using  the  QUILT  build  procedure.  The  resultant  mobility 
quadtree  is  used  directly  by  the  Inference  System  as  well  as  indirectly  via  the  derived 
overlay  of  channelized  areas.  Figure  3-2  illustrates  the  processes  used  in  converting 
CAMMS  mobility  information  into  a  mobility  category  quadtree. 
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Figure  3-2.  Conversion  of  CAMMS  Data  to  Mobility  Quadtree. 


3.1.2  CAMMS  processing:  On-Road  Mobility 

The  Phase  III  MSPES  derives  transportation  feature  information  from  linear 
descriptions  of  transportation  features  in  CAMMS  format.  The  CAMMS  linear  data  format 
is  converted  to  the  format  used  to  import  areal  data  into  the  system.  The  reason  for 
converting  linear  information  to  an  areal  representation  was  made  necessary  by  the 
approach  taken  during  Phase  HI  toward  minefield  site  determination;  namely,  the  evaluation 
of  unique  combinations  of  attributes  rather  than  distinct  positions  in  the  area  of  interest. 
This  necessitated  that  all  the  terrain  attributes  be  maintained  in  a  format  that  enabled  them  to 
be  combined  to  form  unique  combinations  of  attributes.  The  QUILT  GIS  being  used  by 
the  MSPES,  though  it  does  support  storage  of  areal,  linear,  and  point  data  in  quadtree 
format,  does  not  provide  any  integration  between  these  data  types.  As  a  result,  overlays 
used  by  the  MSPES  during  Phase  II  developments  that  had  to  be  combined  using  boolean 
operations  to  determine  unique  attribute  combinations  were  all  maintained  in  areal  format 
quadtrees.  Since  the  Phase  HI  rule  base  incorporates  information  about  areas  adjacent  to  or 
on  road  network  segments,  the  approach  taken  during  Phase  HI  toward  the  CAMMS  road 
network  data  was  to  map  it  onto  a  raster  (at  the  same  resolution  as  that  used  by  the  other 
overlays).  The  result  yielding  data  about  areas  'near'  roads.  Of  course,  there  are  several 
obvious  problems  with  this  naive  approach:  no  attempt  was  made  to  determine  areas  within 
a  specified  distance  of  road  centerlines,  only  raster  elements  touched  by  the  road  centerline 
data  are  considered  'near'  roads;  and,  at  100  meter  resolution,  a  road  segment  could  be  as 
far  as  70  meters  from  the  center  of  the  raster  element  that  the  road  segment  touches. 
However,  the  approach  taken  was  to  demonstrate  how  road  network  data  could  be  utilized 
by  an  inferencing  mechanism,  not  to  provide  a  rigorously  accurate  linear  network 
representation. 
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To  convert  the  linear  network  information  to  the  appropriate  format,  the 
Iine_to_cvl  process  reads  the  linear  data  format  and  creates  the  data  format  used  to  import 
areal  data  into  the  GIS.  Because  of  the  density  of  the  road  network  in  Germany,  options 
for  the  line_to_cvl  process  permit  it  to  process  only  specified  classes  of  roads,  e.g.  those 
classified  as  super  highways  and  primary  roads.  Figure  3-3  illustrates  the  processes  used 
in  converting  CAMMS  On-Road  mobility  information  into  a  areal  quadtree  identifying  areas 
near  roads. 


Roads 


Figure  3-3.  Conversion  of  CAMMS  On-Road  Data  to  Quadtree. 

3.1.3  CAMMS  processing:  Elevation  Data 

Phase  II  rulebase  developments  required  that  enemy  locations  be  provided  in  order 
for  a  more  complete  rulebase  evaluation  to  occur.  One  attribute  of  evidence  used  by  the 
rule  base  that  is  derived  from  enemy  locations  is  the  subset  of  the  area  of  interest  that  is 
visible  from  the  enemy  locations.  To  obtain  this  evidence,  DTED  derived  elevation  data 
that  was  provided  with  the  Lauterbach  attribute  information  was  used.  The  camms_cvl 
process  is  used  to  convert  the  elevation  data,  in  CAMMS  format,  to  a  binary  raster  format. 
The  fslp  process,  which  was  developed  by  adapting  an  algorithm  from  the  Radial  Terrain 
Masked  Area  software  provided  by  the  ETL  Air  Land  Battle  Environment  (ALBE)  group, 
determines  the  forward  facing  slopes  visible  to  enemy  locations.  The  elev_range  process 
converts  the  elevation  data  into  elevation  range  class  polygons,  a  format  more  amenable  to 
storage  in  the  GIS  and  for  terrain  visualization  through  the  user  interface.  Figure  3-4 
illustrates  the  processes  used  to  convert  elevation  data  and  enemy  locations  provided  by  the 
analyst  to  overlays  used  by  the  system  for  user  orientation  or  rule  base  evaluation. 
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Elevation 


P-quadtree  flreal  quadtree 


Figure  3-4.  Conversion  of  CAMMS  Elevation  Data  Quadtrees. 

3.2  Inference  System 

The  Inference  System  that  is  used  by  the  MSPES  is  ERS,  the  Embedded  Rule- 
based  System.  ERS  is  run  as  a  separate  process  by  the  MSPES  applications  that  require 
access  to  the  Inference  System.  ERS,  in  turn  will  start  separate  GIS  Primitive  processes 
corresponding  to  the  pieces  of  geographic  information  that  a  rule  base  requires. 

3.2.1  Rules 

The  purpose  of  the  MSPES  rule  bases  is  to  determine  the  likelihood  of  a  minefield 
being  present  at  a  certain  location.  Five  categories  of  likelihood  may  be  assigned:  Very 
Likely,  Likely,  Possible,  Unevaluated,  and  Not  Likely  Each  one  of  these  goals  is 
represented  by  a  separate  rule  base  goal  node.  The  Phase  III  rule  base  uses  only  the  first 
four  possible  goals. 

The  rule  base  developed  during  Phase  III  is  totally  separate  from  rule  bases  I  and  II 
which  were  developed  during  the  first  and  second  phases  of  this  contract  The  Phase  I  and 
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Phase  II  rule  bases  were  designed  to  support  one  another,  with  one  rule  base  focusing  on 
terrain  factors  and  the  other  focusing  on  battlefield  situation  factors.  The  Phase  in  rule 
base  is  a  single,  stand-alone  rule  base.  With  the  development  of  Method  II  processing,  the 
gains  in  efficiency  made  the  single  rule  base  approach  a  viable  option  and  eliminated  some 
of  the  user  confusion  that  could  result  from  having  to  evaluate  two  rule  bases  in  sequence. 

There  were  several  domain  assumptions  made  under  this  effort.  These  assumptions 
are  listed  below: 

1 .  The  enemy  has  their  mines  placed  in  position  for  a  deliberate  defense. 

2.  The  enemy  can  be  located  anywhere  on  the  map  and  if  the  enemy  position  is 
known,  the  forward  facing  slopes  are  determined  based  on  a  line  of  sight  data 
calculation. 

3.  Possible  minefield  sights  may  be  determined  with  or  without  a  known  enemy 
position. 

4.  The  rule  base  is  constructed  primarily  for  the  data  acquired  to  date,  including: 
mobility,  transportation,  forward  slope,  elevation,  and  canalization.  All  data  are  for 
the  Lauterbach  (Hessen)  quad  in  West  Germany  provided  by  WES  or  subsequently 
derived  from  this  data  through  calculation. 

5.  Evidence  and  hypothesis  nodes  were  incorporated  into  the  rule  base  for  which 
there  was  no  supporting  data.  The  main  purpose  of  this  was  to  consider  these 
possibilities  if  the  data  should  become  available.  Examples  of  this  data  include  key 
installation  data,  man-made  obstruction  data,  and  avenues  of  approach. 

There  are  several  nodes  which  rely  on  data  that  was  not  available  or  currently 
accessible.  These  evidence  nodes  were  included  in  the  rule  base  mainly  to  demonstrate  the 
many  factors  that  help  determine  where  a  minefield  site  may  be  located.  The  majority  of  the 
nodes  included  in  the  rule  base  are  logical  nodes.  The  logical  node  format  allows  the 
analyst  to  answer  yes  or  no  to  every  question  if  running  in  consultation  mode.  The  answer 
provided  by  the  user  is  converted  to  a  degree  of  belief  for  the  evidence  node  before 
inferences  are  propagated.  If  the  analyst  wishes  to  respond  so  that  no  inference  is 
propagated,  or  if  the  system  is  running  automatically  and  the  data  is  not  available,  then  a  0 
is  entered  by  the  analyst  or  returned  by  the  primitive  manager.  A  detailed  list  of  the  Phase 
HI  rule  base  nodes  is  provided  in  Appendix  C. 


The  knowledge  represented  in  the  rule  base  came  from  several  different  sources. 
Information  from  experts  was  incorporated  into  the  rule  base  as  well  as  information  from 
military  mines  placement  doctrine. 

Two  of  the  experts  interviewed  for  minefield  site  prediction  were  Captain  Brian 
Green  of  the  U.S.  Marine  Corps  and  Captain  Jonathan  Clark  of  the  U.S.  Army.  These 
interviews  were  conducted  at  the  Defense  Mapping  School  in  Fort  Belvoir.  VA. 
Knowledge  was  also  obtained  from  in-house  military  experts  with  a  background  in  troop 
movement  and  mines  placement. 

Much  of  the  information  included  in  the  rule  base  came  from  military  doctrine 
included  in  DoD  technical  reports  provided  under  this  contract.  These  reports  include: 

ETL — 0325  Using  Terrain  Analysis  to  Predict  Likely  Minefield  Sites,  Robert  A. 

Falls,  U.S.  Army  Engineer  Topographic  Laboratories,  Ft.  Belvoir,  Va.,  May  1983. 

FMS — 102  Counter-mobility,  Headauarters  Department  of  the  Army,  Washington, 

D.C.,  14  March  1985. 

The  Handbook  for  Employment  Concents  for  Mine  Warfare  Systems,  HQ  U.S. 

Army  Engineer  School,  Ft.  Belvoir,  Va.,  1  August  1986. 

The  mobility  information  was  taken  from  information  provided  primarily  by  Cary 
D.  Butler  of  the  Waterways  Experiment  Station  (WES),  Department  of  the  Army,  Corps  of 
Engineers,  Vicksburg,  MS.  The  mobility  data  covers  many  categories  of  cross  country 
movement  for  both  on-road  and  off-road  movement.  Off-road  categories  include:  USCS 
soil  type;  soil  strength  (in  Cl  or  RCI);  surface  condition  (slipperiness);  snow 
characteristics;  trapezoidal  obstacles  —  slope,  height,  width,  length,  angle,  juxtaposition; 
surface  micro-geometry  (roughness);  vegetation  —  density,  distribution,  visibility.  The 
on-road  prediction  model  includes:  road  type;  soil  type;  soil  strength;  surface  condition; 
snow  data;  slope;  visibility;  micro-geometry,  AASHTO  speed  (road  curvature). 

The  four  goal  nodes  of  the  Phase  HI  rule  base  are  all  propagated  via  Bayesian 
techniques.  This  means  that  the  higher  weight  an  intermediate  node  is  assigned,  the  more 
that  node  will  influence  the  determination  of  the  goal  outcome.  This  can  be  done  with  both 
positive  and  negative  weights.  Using  this  technique  allows  greater  weight  to  be  given  to 
the  intermediate  nodes  for  which  there  was  evidence  or  data.  Of  the  four  nodes  that  are 
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antecedents  of  the  four  goal  nodes,  the  two  for  which  data  existed  to  support  the  evidence 
are  terrain_fac  and  e_location.  Logically,  these  two  nodes  had  the  greatest  affect  on 
the  outcome  of  the  goal  and  were  weighted  with  greater  strength  than  the  other  two 
antecedent  nodes  of  the  goal  nodes:  adjacency  and  key_area. 

3.3  Geographic  Information  System 

During  Phase  II  developments,  modifications  were  made  in  the  way  the  Geographic 
Information  System,  QUILT,  is  used.  The  architecture  of  GIS  usage  by  the  Phase  HI 
MSPES  remains  the  same  as  that  used  in  Phase  I  and  Phase  II:  some  GIS  'primitives'  are 
used  to  feed  information  to  MSPES  application  programs  and  update  the  data  base  while 
other  GIS  primitives  are  used  by  the  Inference  System  to  provide  information  about  terrain 
characteristics  in  support  of  rule  base  evaluation.  The  modifications  made  under  Phase  II 
were  in  two  areas:  the  way  applications  use  GIS  'primitives'  to  feed  them  information,  and 
the  GIS  primitives  used  by  the  Inference  System.  The  discussion  below  details  these 
modifications  for  background  information  and  reference. 

3.3.1  Application  Use  of  GIS 

Previously  the  MSPES  used  slight  modifications  of  the  native  QUILT  capabilities  to 
drive  the  display  of  terrain  information.  Two  modifications  were  made  during  Phase  II  to 
improve  application  performance  using  the  GIS.  The  display  of  areal  quadtrees  is  now 
significantly  faster.  Previously  areal  quadtree  display  was  achieved  by  traversing  the 
quadtree  and  issuing  a  display  command  for  each  quadtree  leaf  node,  specifying  its  upper 
left  comer  coordinate  and  the  size  of  the  leaf  node.  This  resulted  in  large  numbers  of 
display  commands  being  issued  to  the  window  system,  ultimately  creating  a  raster  image  of 
the  quadtree.  Experimentation  showed  that  significant  performance  improvements  could  be 
gained  by  using  adaptations  of  QUILT  code  to  convert  the  quadtree  to  a  raster  directly  and 
then  pass  the  raster  to  the  window  system.  Additions  were  made  to  the  qdisplay  process 
to  accomplish  this  quadtree  to  raster  conversion  process  and  to  pass  the  resultant  raster  to 
the  application  requesting  it  in  a  more  efficient  manner  than  is  done  for  individual  quadtree 
leaf  nodes.  In  addition,  modifications  were  made  to  the  window  system  interface  to 
perform  raster  replication  to  increase  the  scale  of  area  of  interest  displays. 

Several  modifications  were  made  during  Phase  II  to  the  QUILT  system  itself  at 
PGSC’s  request  through  a  subcontract  with  the  University  of  Maryland's  Center  for 
Automation  Research,  the  developers  of  QUILT.  These  modifications  were  in  three  areas: 
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1)  Support  for  the  storage  and  retrieval  of  attribute  data  in  PM  quadtrees;  2)  Support  for  the 
buffering  of  access  to  the  segment  array  used  to  associate  PM  quadtree  nodes  with  line 
segment  identifiers;  and  3)  Making  all  error  messages  go  to  the  standard  error  file,  rather 
than  some  to  the  standard  output. 

During  Phase  ID  the  only  modifications  made  to  the  QUILT  system  itself  were 
several  minor  corrections  to  some  of  the  routines  that  dealt  with  initializing  for  reading  PM 
(linear  data)  quadtrees  that  contained  very  large  collections  of  segments,  and  several 
problems  with  C  functions  that  would  not  pass  a  more  stringently  ANSI-C  compliant  C’ 
compiler  during  the  initial  efforts  aimed  at  porting  QUILT  to  a  VAX/VMS  environment 

Several  modifications  were  made  to  the  qdisplay  process  which  was  derived  from 
a  variety  of  QUILT  applications  to  correct  or  enhance  execution  speed  when  dealing  with 
PM  and  P  (point  data)  quadtrees.  In  addition  several  additions  were  made  to  that  process  to 
support  the  display  of  some  'overlays'  as  gray  scale  overlays  over  color  base  maps. 

3.3.2  GIS  Primitives  used  by  Inference  System 

In  addition  to  the  primitives  developed  under  Phase  II,  such  as  the  determination  of 
whether  an  area's  terrain  tends  to  channel  movement  as  depicted  in  Figures  3-4  and  3-5,  a 
variety  of  modifications  were  made  to  the  GIS  primitives  used  in  Phase  in  rule  base 
evaluation.  Among  these  modifications  were  changes  to  the  inference  system  primitive 
manager  to  better  support  the  handling  of  missing  data,  the  creation  of  new  primitives  to 
support  Phase  III  rulebase  developments,  and  the  creation  of  new  support  GIS  primitives 
used  in  the  process  of  combining  overlays  to  determine  unique  combinations  of  attribute 
values. 
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Figure  3-4.  Conversion  of  Mobility  Quadtree  into  Channelized  Areas. 
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Traversable  Areas 
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Channelized  Areas  From  Skeleton  Segments 


Figure  3-5.  Determining  Channeled  Movement  Areas  from  Areas  of  Mobility 


The  modifications  to  the  primitive  manager  to  support  better  handling  of  unavailable 
data  were  made  so  that  the  Phase  II  rulebase  could  incorporate  all  the  aspects  of  minefield 
doctrine  that  knowledge  engineering  resulted  in.  With  these  modifications,  as  new  data 
becomes  available,  only  the  primitives  associated  with  that  new  data  need  to  be  developed, 
no  inference  system  changes  are  required.  Likewise,  if  the  analyst  wants  to  see  what 
impact  a  particular  terrain  factor  has  on  rule  base  evaluation,  the  system  can  simply  be  told 
that  data  is  not  available  without  making  any  rule  base  or  software  modifications. 

Several  new  GIS  primitives  were  created  to  support  Phase  HI  rule  base  evaluation. 
These  included  primitives  to  provide  information  about  the  minimum  distance  ranges  to 
enemy  locations  (dist_to_eloc),  and  whether  areas  are  visible  or  not  (visible).  In 
addition,  a  new  version  of  the  primitive  that  drives  the  minefield  site  prediction  manuscript 
creation  process  was  developed  in  support  of  Method  II  processing.  This  procedure. 
qscan_dmpupd,  identifies  areas  with  unique  combinations  of  attributes,  passes  the 
identifier  to  the  Create  Manuscript  application  for  evaluation  by  the  inference  system, 
and  updates  that  area  and  every  other  area  with  the  same  combination  of  attributes  with  the 
inference  system  evaluation. 

Finally,  a  number  of  new  GIS  primitives  were  created  to  support  the  creation  of  the 
manuscript  template:  the  quadtree  with  identifiers  for  each  combination  of  attributes  derived 
from  the  area  of  interest  overlays.  The  primitives  addall,  addall_nonzero,  changeall, 
compaU,  maxall,  and  orall,  which  are  actually  simple  subroutines  in  a  larger  controlling 
procedure  body,  implement  simple  quadtree  operations  required  by  the  manuscript  template 
creation  process.  Similarly,  the  GIS  primitives  e!oc_dist,  elev_range,  and  fslp  create 
quadtrees  defining  the  minimum  distance  range  to  enemy  locations,  elevation  range  classes 
from  elevation  values,  and  areas  visible  from  enemy  locations  respectively. 

3.4  Window  System  Interface 

One  of  the  goals  of  Phase  II MSPES  development  was  to  ease  the  transition  of  the 
user  interface  portion  of  the  MSPES  to  the  Phase  ID  target  system,  a  VAXStation  II/GPX 
running  the  VMS  operating  system.  To  that  end,  it  was  decided  that  the  user  interface  used 
by  MSPES  applications  would  use  a  non-proprietary,  portable  window  system  graphics 
package:  the  X  Window  System.  Although  this  transition  to  the  target  system  did  not 
occur,  the  MSPES  window  interface  development  continued  under  X  Windows.  A 
detailed  discussion  of  the  X  Window  system  is  provided  in  Section  3.4.1  of  the  Phase  II 
Final  Report  [ETL-0534,  May  1989]. 
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3.4.1  Application  Control  Panels 

Each  of  the  MSPES  applications  (View  Map,  Create  Manuscript,  Input 
Map,  Edit  Rule  base,  and  MSPES  Help)  has  a  control  panel.  These  control  panels 
consist  of  command  buttons  and  ancillary  label  information  such  as  the  name  of  the  current 
Area  of  Interest,  the  current  manuscript,  etc.  These  application  panels  remain  essentially 
the  same  as  those  developed  under  Phase  n. 

The  MSPES  control  panels  consist  of  a  vertical  array  of  buttons  and  labels.  This 
arrangement  has  several  benefits.  First,  the  vertical  arrangement  is  similar  to  the  ALBE 
testbed  user  interface.  It  is  an  important  aspect  of  user  interface  design,  particularly  of 
applications  which  use  direct  manipulation  interfaces,  that  the  user  interface  match  the 
user's  conceptual  model.  The  MSPES  uses  a  portable  window  system  to  create  a  familiar 
looking  environment  in  which  to  perform  interactions  with  geographic  information.  The 
ALBE  testbed  equivalent  to  the  MSPES  control  panels  are  the  command  menus  which 
appear  on  the  alpha-numeric  terminal  and  the  control,  message,  and  legend  areas  that 
appear  along  the  right  margin  of  the  ALBE  graphic  terminals.  Secondly,  the  arrangement 
of  components  within  application  windows  is  automatically  maintained  by  components  of 
X  Toolkit  widget  sets;  no  MSPES  code  had  to  be  developed  to  create  this  arrangement. 
The  form  widget  permits  child  widgets,  the  buttons,  labels,  and  graphic  canvases  used  by 
the  MSPES,  to  specify  relative  positioning  hints  to  the  parent  form.  These  hints  allow  the 
child  widgets  to  maintain  their  relative  positions  after  resize  events  caused  by  the  user 
modifying  the  application  window  arrangement.  Finally,  the  default  position  for  the 
MSPES  control  panels  is  along  the  right  hand  side  of  the  graphics  display.  By  positioning 
the  control  panel  along  the  sides  of  the  graphic  terminal  a  larger,  squarer  area  is  left  free  for 
the  graphics  display. 

Command  buttons  on  application  control  panels  sometimes  appear  'grayed  out'  and 
cannot  be  selected  by  the  user.  This  is  controlled  by  the  need  to  satisfy  prior  conditions 
before  the  command  can  be  applied.  For  example,  the  DISPLAY  button  appears  grayed 
out  on  the  View  Map  application  control  panel  until  the  user  has  selected  an  overlay  or 
minefield  site  prediction  manuscript  using  the  LIST  MAPS  button.  In  this  way  the  user  is 
led  through  the  process  of  using  the  application  without  having  to  remember  a  particular 
command  sequence. 
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3.4.2  Graphic  Viewport 


The  graphic  viewport  is  where  maps  and  manuscripts  are  displayed  for  MSPES 
applications  that  use  them.  The  MSPES  user  interface  displays  the  graphic  viewport  to  the 
left  of  the  control  panel  in  an  area  that,  by  default,  uses  most  of  the  screen  real  estate. 
Changes  to  the  graphic  viewport  made  under  Phase  m  included  support  for  the  display  of 
two  overlays  at  once,  scrollbars  to  permit  the  display  of  maps  larger  than  the  dimension  sof 
the  application  window,  and  additional  use  of  the  X  resource  database  to  enhance 
customization.and  adaptation  of  the  user  interface  without  requiring  recompilation  of  source 
code. 


Graphic  viewports  are  implemented  using  a  simple  widget  created  for  MSPES 
applications.  This  widget  is  implemented  by  the  routines  in  the  G window  library.  A 
Gwindow  widget  object  provides  methods  for  drawing  text,  lines,  polygons,  points,  and 
displaying  rasters,  among  other  capabilities.  Modifications  were  made  to  the  Gwindow 
widget  procedures  to  support  the  display  of  two  overlays  at  once  using  X  Window  System 
colormap  manipulations.  A  colormap  is  created  with  two  sets  of  32  colors  each.  In  one  set 
the  32  colors  are  used  to  display  color  base  maps.  The  other  set  of  32  'colors'  defines  a 
gray  scale  which  is  used  to  display  overlays  on  top  of  color  base  maps.  The  pixel  values 
used  for  the  second  set  of  32  ’colors'  parallel  the  pixel  values  used  for  the  first  set.  except 
that  they  have  one  additional  bit  set.  In  effect,  the  second  set  of  colors'  pixel  values  defines 
a  bit  plane  within  the  Gwindow  widget  display  area.  By  enabling  just  that  bit  plane  when 
overlays'  are  displayed,  the  color  base  map  pixels  are  mapped  into  overlay  gray  shades. 
The  implementation  of  these  functions  is  hidden  from  applications  and  is  readily  modified 
to  effect  performance  or  functional  improvements.  The  overlay  capabilities  are  accessed  by 
application  requests  that  the  Gwindow  widget  select  the  'next'  overlay. 

Figure  3-6  depicts  the  MSPES  View  Map  application  user  interface,  illustrating  a 
typical  display  using  the  components  referred  to  above. 
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3 . 5  User  Interface 


Under  Phase  Ed  development  a  number  of  modifications  were  made  to  the  user 
interface  used  by  MSPES  applications  to  facilitate  customization  to  user  requirements  and 
modification  to  the  graphic  appearance  of  applications.  These  modifications  include 
enhancements  to  the  way  in  which  the  system  'knows'  about  overlays  associated  with  an 
area  of  interest  and  the  ability  for  the  analyst  to  edit  the  Enemy  Location  overlay  while 
another  base  map  is  being  displayed  to  indicate  enemy  location  by  cursor  point  and  click. 
Multiple  enemy  locations  may  be  delimited. 

During  Phase  II,  the  Explain  Manuscript  and  Edit  Map  applications  were 
incorporated  as  user-selected  'modes’  of  the  View  Map  application.  Using  the  'grayed  out' 
user  feedback  mechanism,  these  modes  are  only  available  when  appropriate.  For  example, 
explain  mode  is  available  only  when  a  manuscript  is  being  displayed  and  not  while  edit 
mode  is  active.  While  viewing  a  manuscript,  if  the  user  wants  to  see  an  explanation  from 
the  inference  system  of  the  rule  base  logic  that  led  to  a  minefield  likelihood  categorization, 
the  user  clicks  on  the  EXPLAIN  button.  This  causes  the  inference  system  to  be  primed  and 
an  explanation  window  appears.  Clicking  on  a  manuscript  location  causes  the  inference 
system  to  re-evaluate  the  specified  position  and  permits  the  user  to  interact  directly  with  the 
inference  system  via  the  explanation  window.  This  situation  is  illustrated  in  Figure  3-7. 
Tnis  modification  was  kept  under  Phase  ID. 

The  X  implementation  of  the  MSPES  control  panels  permits  some  of  the  appearance 
of  the  user  interface  to  be  customized  readily  by  the  user  similar  to  the  way  in  which  user 
preferences  for  text  editing  tools  may  be  specified.  User  interface  customization  is 
accomplished  by  specifying  resource  strings  in  an  .Xdefaults  file  or  by  loading  resource 
definitions  into  the  window  system  server.  Using  these  application  resource  specifications, 
the  user  can  modify  what  font  is  used  for  command  buttons  and  labels  in  the  control 
panels,  the  label  text  itself,  the  width  of  borders,  the  color  of  borders,  etc.  The  initial 
position  and  size  of  the  MSPES  user  interface  windows  is  likewise  determined  by  resource 
definitions  that  the  user  is  free  to  over-ride  with  private  specifications.  System  default 
values  are  provided  and  are  loaded  as  the  applications  are  started.  System  default  values 
may  be  overridden  by  the  user  loading  replacement  values  prior  to  application  start  up. 
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The  legend  text  associated  with  each  type  of  map  used  is  stored  in  a  text  file  that  is 
read  and  interpreted  when  the  applications  start  a  new  map  display.  Under  Phase  II 
development,  the  association  between  overlays  and  the  file  describing  the  overlay’s  legend 
was  hardwired  into  the  applications.  This  made  adding  new  types  of  data  to  the  system  a 
matter  of  recompiling  source  code.  Under  Phase  HI,  the  information  about  what  overlays 
are  associated  with  an  area  of  interest,  how  the  user  identifies  those  overlays,  how  those 
overlays  are  to  be  displayed,  how  those  overlays  are  created,  and  what  GIS  primitives  are 
associated  with  those  overlays  for  use  during  rule  base  evaluation  is  all  specified  in  a  text 
file  that  is  read  and  interpreted  when  the  user  initiates  the  selection  of  an  overlay.  This 
enhancement  makes  the  act  of  providing  the  system  with  knowledge  about  what  overlays 
are  associated  with  an  area  of  interest  and  how  they  are  to  be  utilized  a  matter  of  editing  the 
area  of  interest  overlays  file. 

Figures  3-8  through  3-10  illustrate  the  user  interface  and  the  enemy  location  facility 
using  the  elevation  data  overlay  as  a  background  display.  Figure  3-8  shows  five  enemy 
installations,  displayed  as  an  overlay,  clustered  on  two  higher  elevation  areas  on  the  left 
center  of  the  an  elevation  range  map,  which  is  displayed  as  a  color  base  map  (here  rendered 
in  black  and  white).  Figure  3-9  depicts  the  minefield  belts  of  a  deliberate  defense 
established  by  the  enemy.  These  belts  or  areas  around  the  enemy  location  indicate  varying 
weights  contributed  to  the  degrees  of  likelihood  of  a  minefield  site.  Figure  3-10  delimits 
those  areas  which  are  visible  to  the  enemy  from  enemy  locations,  shown  as  an  overlay,  and 
the  surrounding  topography  shown  as  a  color  base  map. 
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4. 


Evaluation  and  Recommendations 


The  following  discussion  focuses  on  the  evaluation  of  the  Phase  HI  developments 

and  the  recommendations  for  future  work  involving  the  MSPES. 

•  The  Phase  HI  rule  base  could  be  extended  and  enhanced  to  more  fully  model  the 
minefield  site  prediction  process  if  more  data  were  available  in  digital  form.  Data 
formats  and  availability  were  the  greatest  problems  encountered  during  MSPES 
system  development  A  large  amount  of  effort  was  expended  on  translating 
different  data  formats  and  circumventing  data  that  was  not  available.  An  advantage 
of  this  is  that  the  rule  base  design  was  constructed  to  accommodate  data  availability 
so  that  the  system  could  perform  even  if  data  were  not  accessible. 

•  Given  a  different  domain  or  even  the  current  minefield  site  prediction  problem,  the 
GIS  functionality  of  the  MSPES  could  be  extended.  This  includes  both  how  the 
system  uses  the  GIS  functions  and  what  GIS  functions  are  available  for  use. 
Establishing  a  'GIS  toolbox'  would  greatly  expand  the  utility  and  application  of  the 
MSPES.  For  example,  implementing  an  interface  between  the  core  MSPES  and  a 
number  of  GIS  such  as  GRASS,  yet  retaining  the  quadtree  capability,  would 
greatly  enhance  the  current  system. 

•  Porting  the  MSPES  or  interfacing  the  MSPES  to  the  ALBE  environment  would 
provide  a  valuable  Tactical  Decision  Aid  (TDA)  tool.  The  original  scope  of  this 
effort  called  for  the  porting  of  this  system  to  the  ALBE  system.  The  MSPES 
represents  technology  mature  enough  to  move  into  the  operations  and  development 
environment  [PGSC,  1989]. 

•  Exploring  application  of  this  system  to  other  problem  domains,  including  the  use  of 
cooperating  expert  systems,  could  provide  useful  information  for  future 
development  efforts  in  support  of  the  modem  battlefield 

•  The  MSPES  should  be  reviewed  and  evaluated  by  both  terrain  analysts  and  combat 
engineers  to  assess  the  utility  of  combining  inferencing  systems  and  geographic 
information  systems  to  .automate  some  of  their  functions. 
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Appendix  B  -  Terms  and  Abbreviations 


CCM 

CVL 

DEC 

ERS 

ETL 

GIS 

GPX 

i/o 

MTT 

MSPES 

PGSC 

PM 

QUILT 

SunOS 

toolkit 

UNIX 

VAX 

VMS 

widget 

Xll 


Cross  Country  Movement 

Computer  Vision  Laboratory.  Refers  to  a  raster  data  format  used  as  the 
input  format  for  QUILT  areal  quadtrees. 

Digital  Equipment  Corporation 

Embedded  Rule-Based  System 

U.S.  Army  Engineer  Topographic  Laboratories 

Geographic  Information  System 

A  trademark  of  DEC,  a  Graphics  Accelerator  chip  set 

input/output 

Massachusetts  Institute  of  Technology 

Minefield  Site  Prediction  Expert  System 

PAR  Government  Systems  Corporation 

Polygonal  Map,  a  type  of  quadtree  used  to  store  linear  data. 

A  GIS  developed  by  the  University  of  Maryland  Center  for  Automation 
Research. 

A  trademark  of  Sun  Microsystems  Inc.,  the  operating  system  used  for  the 
prototype  and  Phases  II  &  ID  MSPES. 

A  set  of  functions  to  simplify  the  development  of  application  user  interfaces. 

A  trademark  of  AT&T  Bell  Laboratories,  a  multi-processing  computer 
operating  system 

A  trademark  of  DEC,  standing  for  Virtual  Address  extension,  describes  a 
family  of  32  bit  super-minicomputer 

A  trademark  of  DEC,  standing  for  Virtual  Memory  System,  a  high 
performance  operating  system  that  runs  on  the  VAX  family  of  computers. 

A  user  interface  component  in  Xll  with  associated  input  and  output 
semantics  that  implements  a  particular  direct  manipulation  user  interface 
style. 

A  trademark  of  MIT,  the  X  Window  System 
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Appendix  C  -  Phase  III  Rule  Base 


The  following  lists  detail  the  rule  base  developed  under  Phase  ID. 


Goals 

Unevaluated 

Possible 

Likely 

Very 

Intermediate  Hypothesis 
terrain_fac 
adjacency 
ejocation 
key_area 
ccm_possible 
fast_ccm 
ccm 

Evidence  Nodes 

ccm:  a  choice  node  with  a  primitive,  this  eliminates  having  to  have  each  node  for  a 
set  of  mutually  exclusive  function  results  call  the  same  primitive  function.  The 
primitive  ccm_class  is  called  once  with  the  resulting  value  compared  to  the  seven 
specified  answers.  The  seven  ccm  categories  with  a  brief  description  are: 

1 )  go:  the  region  can  support  speeds  greater  than  30.0  km/hr, 

2)  restricted:  the  region  allows  speeds  between  15.0  and  30.0  km/hr, 

3)  slow:  the  region  permits  speeds  between  5.0  and  15.0  km/hr, 

4)  very_slow:  the  region  permits  speeds  between  1.5  and  5.0  km/hr, 

5)  no_go:  the  region  permits  speeds  less  than  1 .5  km/hr, 

6)  no_go_water:  the  region  contains  open  water  that  cannot  be  crossed, 

7)  built_up:  built-up  areas  restrict  movement  of  battle  tanks. 

deliberate:  a  choice  node  with  a  primitive,  this  eliminates  having  to  have  each 
node  for  a  set  of  mutually  exclusive  function  results  call  the  same  primitive 
function.  The  primitive  distance_to_e_loc  is  called  once  with  the  resulting  value 
compared  to  the  eight  specified  answers.  The  eight  possible  responses  with  a  brief 
description  are: 
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>=3100:  the  region  is  located  beyond  the  range  for  the  first  minefield 
>=2900_<3100:  the  region  is  located  within  the  first  minefield  belt 
>=1600_<2900:  the  region  is  located  between  specified  minefield  belts 
>=1400_<1600:  the  region  is  within  the  second  obstacle/minefield  belt 
>=450_<1400:  the  region  is  located  between  specified  minefield  belts 
>=250_<450:  the  region  is  within  the  third  minefield  belt 
>=0_<250:  the  region  is  located  between  specified  minefield  belts 
<0:  the  region  is  located  an  unknown  distance  from  minefield  belts 

e_loc_distance:  a  choice  node  with  a  primitive,  this  eliminates  having  to  have 
each  node  for  a  set  of  mutually  exclusive  function  results  call  the  same  primitive 
function.  The  primitive  distance_to_e_loc  is  called  once  with  the  resulting  value 
compared  to  the  four  specified  answers.  The  four  possible  responses  with  a  brief 
description  are: 

>5000:  region  is  beyond  range  for  enemy  mines  or  visibility 
>3000-5000:  region  is  visible  to  enemy  but  located  outside  mine  belts 
0-3000:  region  is  within  range  of  enemy  minefields 

unknown:  region  is  located  an  unknown  distance  from  enemy  position  (enemy 
positions  not  specified) 

canal_evid:  Skeletonization  and  mobility  data  indicates  the  current  area  has 
characteristics  of  a  canalized  area.  Canalized  areas  have  a  higher  likelihood  of  being 
mined. 

road_adj:  Transportation  data  indicates  a  road  is  adjacent  to  current  area.  Mine 
documentation  indicates  areas  adjacent  to  roads  are  likely  to  be  mined. 

inter_adj:  Transportation  data  indicates  an  intersection  of  roads  is  adjacent  to  the 
current  area.  Mine  documentation  indicates  areas  adjacent  to  road  intersections  are 
more  likely  to  be  mined. 

bridge_adj:  Transportation  data  indicates  a  bridge  is  adjacent  to  the  current  area. 
Mine  documentation  indicates  areas  adjacent  to  bridges  are  more  likely  to  be  mined. 
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ford_adj:  Transportation  data  indicates  a  known  fording  site  is  adjacent  to  current 
area.  Mine  documentation  indicates  areas  adjacent  to  known  fords  are  more  likely 
to  be  mined. 

near_e_loc:  If  current  area  is  within  5000  meters  of  the  enemy  there  is  a  greater 
likelihood  of  being  visible  to  the  enemy  and  within  range  of  enemy  artillery. 

obstruction:  Since  mines  are  designed  to  slow  down  and  modify  patterns  of 
mobility,  the  presence  of  other  means  to  accomplish  this,  such  as  obstacles,  is  a 
positive  indicator. 

visible:  The  current  area  has  a  greater  chance  of  being  mined  if  it  is  within  sight  of 
the  enemy  and  within  range  of  enemy  artillery. 

range:  The  current  area  has  a  greater  chance  of  being  mined  if  it  is  within  3000 
meters  of  enemy  position.  Based  on  a  deliberate  defensive  posture  the  enemy  will 
place  mines  in  three  bands  starting  at  3000  meters  out  from  their  current  position. 
The  second  and  first  bands  are  laid  at  1500  meters  and  300-400  meters, 
respectively. 

strongpoint:  Areas  that  are  suspected  of  possessing  strongpoints  will  try  to 
canalize  the  movement  of  tanks.  Strongpoints  are  designed  to  be  a  cork  in  a 
bottleneck  formed  by  terrain,  obstacles,  and  units.  It  is  essentially  an  antitank  nest 
proving  incapable  of  being  bypassed. 

ave_approach:  If  the  current  position  is  within  an  avenue  of  approach  there  is  a 
high  likelihood  of  mines. 

installation:  Minefields  will  be  placed  around  key  installation  features.  Minefield 
doctrine  indicates  mines  are  likely  near  and  around  key  installation  features  such  as 
airports,  helicopter  landing  zones,  and  enemy  military  areas. 

coastal:  Tests  to  determine  if  current  area  is  within  a  coastal  area.  Minefields  are 
placed  along  flat  coastal  areas  to  inhibit  beach  landings  of  troops  and  artillery. 
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